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Overview 


+ MOSSG presents: 

♦ Preliminary Priorities - Services 

♦ Preliminary Priorities - Core Capabilities 

+The Priorities - Services are what was expected from 
MOSSG, so we are presenting it first. 

♦ With “Warnings” 

+ The Priorities - Core are presented second. 

+ However, the MOSSG believes the Priorities - Core are 
more important and are actually prioritized over all of the 
Priorities - Services. 


PRIORITIES - SERVICES 


^Warnings about “Preliminary” Priorities - Services 

' + The CCSDS requested that Preliminary Priorities should be delivered to SM&C to guide their work 
into CY15. 

+ The MOSSG warns that “Preliminary” priorities are dangerous because “Final” priorities may be 
greatly modified, after the MOSSG completes our other analyses of Mission Operations Systems 
approaches. 

+ At the current pace, in the absence of funding for additional MOSSG work, the final analysis will 
not be available for years. 

+ However, the MOSSG concedes that “Preliminary” priorities are better than no priorities at all for 
2015 . 

+ In particular, the MOSSG has within it’s range of possible options to assert that an SM&C Service 
Interface may not be the right option for some data types and services. 

♦ As with the current ISS program, it may be that some functions are best done simply with 
“Shared Software” or “Remote Login” or other centrally-controlled functions, rather than a 
Peer SOA environment. 

+ Final MOSSG priorities, years from now, may advocate non-SM&C approaches for some of the 
services on the following priority list. 

+ Our understanding is that SM&C did not do an “operations concept” tradeoff on what data 
functions or services are best served by SOA (or other) approaches. It was a given that SM&C 
would do all services via SOA. MOSSG is not similarly constrained. 

+ Result: CCSDS and SM&C embark on this work at risk. It may be successfully completed, but if 
analysis indicates shared software is more effective for any given service, the SM&C SOA 
developed for that service may never be used. 

+ This is more indication that SM&C should focus on core capabilities more than branching out to 
new services. 
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Context of MOSSG Work 


+ MOSSG recognizes that the MOSCG survey was a 
valuable result. 

♦ Excellent approach to cast a wide net for the needs of 
many missions 

+ However, the MOSSG is doing other analyses that are 
not yet complete. 

♦ “Drill down” into more detailed study of two complex 
missions, analyzing services and their resulting 
appearance in “IOAG Service Catalog 3”. 

♦ Overall study of operational concepts for interoperability - 
Validate SM&C direction with understanding of how it fits 
into operations. 

+ For “Preliminary Priorities-Services”, only the MOSCG 
Survey is available as a starting point. 
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Source Data - MOSCG Survey Results 


Legend 

MO Systems data exchange (CCSDS) 
MO Practices (Flight Ctrl Teams) 


General Questions 


PRIORITY 1 


PRIORITY 2 


PRIORITY 3 

Telemetry 


Planning - Crew Activities (systems) 


Planning - Science 

Navigation 

Planning - Planetary Surface 

Antenna Management 

File Transfer 


Logistics 


Crew Medical 

Planning - Communications Passes 


Realtime Voice 


Onboard Buffer Management 

File Uplink/Downlink 


Time Synchronization/Correlation 
Planning - Crew Activities (procedures) 


Video Systems Control 

Archive 

Launch Processing 

Realtime Commanding 

Realtime Video 

IOAG Coordination of Practices 

Preplanned Commanding 

Training - Flight Crew 

Onboard Maintenance 

Planning - Vehicle Systems 

Train - Ground Crew 

Playback Video 

Command Responses 

Telerobotics 

Launch Operations 

Security 

Planning - Spacecraft Systems 

Playback Voice 

Flight Control Emergency Support 


Command History 


Software Management 

Service Catalog 3 




Flight Control - LEOP 



Flight Control - LEO 
Flight Control -Cruise 
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Step 1: Map Survey results to (future) SM&C Books 


Init. 


Pri. 

Priority In Order from MOSCG Survey 

SM&C Book topic 

Comments 

1 

Telemetry 

M&C Services (in work) 

Virtually complete 

1 

Navigation 

Navigation Service 

Not recognized by NAV WG 

1 

File Transfer 

File Management 


1 

Planning - Communications Passes 

? CSSM? 

Maybe CSSM duty instead of SM&C? 

1 

File Uplink/Downlink 

File Management 

Uses CFDP but augments w/ mgt. 

1 

Archive 

Archive Service 


1 

Realtime Commanding 

M&C Services (in work) 


1 

Preplanned Commanding 

M&C Services (in work) 

Not clear if covered by M&C now. 

1 

Planning - Vehicle Systems 

Planning Services 


1 

Command Responses 

M&C (?) Should be? 

Not clear if covered by M&C now. 

1 

Security 

NEW Security Service 


2 

Planning - Crew Activities (systems) 

Planning Service 


2 

Planning - Planetary Surface 

Planning Service (?) 


2 

Logistics 

NEW Logistics Service 


2 

Realtime Voice 

NEW Voice Service (?) 


2 

Time Synchronization/Correlation 

Time Service 

Service would require TS/C WG formation 

2 

Realtime Video 

NEW Video Service 


2 

Telerobotics 

Telerobotics Service 


2 

Command History 

M&C (?) 

Not clear if covered by M&C now. 

3 

Antenna Management 

NEW or M&C Svc? 


3 

Crew Medical 

NEW Crew Medical 

Unique but critical data type. 

3 

Onboard Buffer Management 

Remote Buffer Mgt Svc. 

Unclear if this is a priority at all. 

3 

Video Systems Control 

NEW Video Service 


3 

Onboard Maintenance 

NEW Onboard Maintenance 

Maybe part of Logistics? 

3 

Playback Video 

NEW Video Service 


3 

Playback Voice 

NEW Voice Service 


3 

Software Management 

NEW Software Management 




Step 2 - Group sub-services and reprioritize 


Init. Pri. 

Priority In Order from MOSCG 
Survey 

SM&C Book topic 

Comments 

SM&C Book topic 

Avg Priority from Col. A 

1 

Archive 

Archive Service 


Archive Service 

1 

1 

File Transfer 

File Management 


File Management 

1 

1 

File Uplink/Downlink 

File Management 

Uses CFDP but augments w/ mgt. 

Navigation Service 

1 

2 

Command History 

M&C (?) 

Not clear if covered by M&C now. 

NEW Security Service 

1 

1 

Command Responses 

M&C (?) Should be? 

Not clear if covered by M&C now. 

M&C 

1.2 

1 

Telemetry 

M&C Services (in work) 

Virtually complete 

Planning Service 

1.5 

1 

Realtime Commanding 

M&C Services (in work) 


NEW Logistics Service 

2 

1 

Preplanned Commanding 

M&C Services (in work) 

Not clear if covered by M&C now. 

Telerobotics Service 

2 

1 

Navigation 

Navigation Service 

Not recognized by NAV WG 

Time Service 

2 

3 

Crew Medical 

NEW Crew Medical 

Unique but critical data type. 

NEW Voice Service 

2.5 

2 

Logistics 

NEW Logistics Service 


NEW Video Service 

2.7 

3 

Onboard Maintenance 

NEW Onboard Maintenance 

Maybe part of Logistics? 

NEW Crew Medical 

3 

3 

Antenna Management 

NEW AntMan or M&C Svc? 


NEW Onboard Maintenance 

3 

1 

Security 

NEW Security Service 


NEW Antman or M&C Svc? 

3 

3 

Software Management 

NEW Software Management 


NEW Software Management 

3 

2 

Realtime Video 

NEW Video Service 


Remote Buffer Mgt Svc. 

3 

3 

Video Systems Control 

NEW Video Service 




3 

Playback Video 

NEW Video Service 



3 

Playback Voice 

NEW Voice Service 




2 

Realtime Voice 

NEW Voice Service (?) 




2 

Planning - Crew Activities 
(systems) 

Planning Service 




2 

Planning - Planetary Surface 

Planning Service (?) 




1 

Planning - Vehicle Systems 

Planning Services 




1 

Planning - Communications 
Passes 

Planning Svc or CSSM? 

Maybe CSSM duty instead of 
SM&C? 



3 

Onboard Buffer Management 

Remote Buffer Mgt Svc. 

Unclear if this is a priority at all. 



2 

Telerobotics 

Telerobotics Service 




2 

Time 

Synchronization/Correlation 

Time Service 

Service would require TS/C WG 
formation 
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Final Services Priorities and Sanity Check 


SM&C Book topic 


Priority 


Archive Service 

1 

File Management 

1 

Navigation Service 

1 

NEW Security Service 

1 

M&C 

1.2 

Planning Service 

1.5 

NEW Logistics Service 

2 

Telerobotics Service 

2 

Time Service 

2 

NEW Voice Service 

2.5 

NEW Video Service 

2.7 

NEW Crew Medical 

3 

NEW Onboard 
Maintenance 

3 

NEW Antman or M&C 
Svc? 

3 

NEW Software 
Management 

3 

Remote Buffer Mgt Svc. 

3 


Many more mission facilities need remote archive access 
than need realtime telemetry. Therefore the Archive 
priority compared to M&C makes sense. 

File Management and Navigation are understandable 
priorities for more missions than M&C. 

Security services responses may be driven by media hype 
more than threats. Security controls are in place, just not 
in an interoperable way. A service interface for 
cooperative or federated security may not be such a high 
priority, but SM&C should begin discussions with the 
Security WG about potential needs for service interfaces 
to share identities, etc. 

Planning service position below Archive and File 
Management, but above Logistics and Telerobotics seems 
about right. 

Other lower priority services also seem about right 
except... 

Crew Medical has a very small mission set (only joint 
human missions) but it is an incredibly critical and life- 
critical function. It is probably prioritized too low in this list. 
Perhaps Remote/Onboard Buffer Management is not well 
understood, but it seems appropriate to be lowest on the 
list or even deleted. 9 




PRIORITIES - CORE 


General Context of Priorities-Core 


+ These are provided as work that needs to be done in 
order for agencies to realize the vision of improvements 
that should result from a standardized service oriented 
architecture, including standardized service interfaces. 

+ Some of this work may already be underway in CCSDS; 
The MOSSG doesn’t have a full understanding of current 
SM&C activities within the working group. 

+ This is not intended as criticism of CCSDS, simply a 
statement of forward work that is needed. 
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ome MOSSG Observations 


+ The MOSSG has observed: 

♦ The “plug-n-play” presentation material distributed by SM&C builds 
expectations of minimal effort (outside of the standards) required by 
service providers and consumers to enable interoperability. 

♦ There was a large ICD-like PID (ICD equivalent) required for the JSC/DLR 
prototype, and extensive JSC/DLR coordination required to execute the 
prototype 

♦ In assessments of the MO Services by individuals that are external to the 
working group, concerns have been raised over abstract vs. concrete 
specifications, blue/magenta book issues, etc. 

+ We think these observations are related, and they indicate that even 
the “completed” services (M&C and underlying core standards) are 
not yet at full standardization maturity. 

+ It is more important to achieve full maturity of the existing standards 
as a higher priority than investing resources in new services. 

♦ Resources really means *competing* resources - for example the 
resources for the telerobotics service generally do not compete for the 
resources in in the core MO Services work. 

♦ The MOSSG can’t say whether other startup efforts (Planning BOF, etc.) 

compete with SM&C resources. CCSDS should consider this. 1 


Some MOSSG Observations 


+ SM&C seems to be developing component services, not fully developed 
service interfaces. 

+ The “service interface” that is specified by the end-to-end compilation of 
the SM&C documents does not meet the expectations of “plug-n-play” 
or automated configuration. 

♦ Expectations are described in SM&C presentations, and in the MOSCG 
presentation to the IOP. 

+ The probable area to “augment” in the SM&C specifications is the 
“configuration service” in the Common Services document. 

+ However other new specifications may be required - Unknown. 

+ The augmented specifications should: 

♦ Move towards “automated configuration services” 

♦ Move towards “discovery of services” that can be genuinely exposed by 
a service provider, discovered by a service consumer. 

♦ Focus on exposing (publishing) the capabilities and characteristics of a 
service to an authorized subscriber (factoring in security concerns). 
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More discussion on the Plug-n-Play capabilities 


Some things that need to be done in order to realize the plug-n-play 
vision of service interfaces: 

♦ Service Interfaces should allow “discovery” of some material that was 
documented manually in the JSC-DLR “PID” (ICD). 

+ Some facility-unique data (firewall rules, IP addresses) must necessarily be 
separately agreed to in an ICD... but not that much. 

♦ Service Interfaces should be built so a “client” service can be built and/or 
integrated by a consumer that will connect to a service provider in an 
automated way (implementable “blue book fashion”) 

♦ Current M&C service does not realize this vision. 

+ It may be that this is primarily or even exclusively a function of 

automation in the “Configuration Service” 

♦ A fully expanded Configuration Service may be significant enough to be a 
standalone blue book. 

♦ It *may* be the final blue book in the SM&C end-to-end service 
specifications that is needed to offset the concerns that have been raised 
about “abstract” and “non-blue” specifications. 
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Automated Configuration Services 


What follows is the “vision” of the capabilities 

+ A Client in a control center that needs to be a data consumer can 
reach the programmatic interface (Web services or RESTful or 
JSON?) in another control center and “discover” services”. 

+ The developer/controller operating the client can (to the maximum 
extent possible) view a list of services, and for the telemetry 
services, he can view (for example) the parameters available. 

+ He can select those parameters that he needs on a display and 
place them on that display. 

+ He can then “run” that display and it will fetch the required telemetry. 

+ “to the maximum extent possible” means there are some vehicle- 
unique or program-unique things that can’t be discoverable. But it is 
a lot more discoverable than provided by the current SM&C service 
concept. 
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Automated Configuration Services 


+ “Automated” term means that it is more automated than the current 
SM&C architecture configuration services (discovery capabilities). 

+ Configuration Services is a service in the “Common Services” book. 
+ Right now it’s basic, not automated. 

+ Configuration services are central to discovery capabilities in the 
service interface. 


+ Proposed recommendation to SM&C: “finish” the Configuration 
services, “finish” discovery of services for M&C as a higher priority 
than starting new application services. 

+ Result should be a specification that is “blueish” - An organization 
can build a consumer client that can connect to an existing service 
provider with minimal program-specific ICDs required. 
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Program Scenario - where we want to get to 


+ A service provider already has a service interface for Telemetry that complies with the SM&C 
document suite. 

+ A new service consumer needs to develop a service interface that will connect with it to access 
telemetry. 

+ The organizations agree to use SM&C M&C Standards. Each organization studies these documents: 

♦ MAL, COM, M&C, etc... (SM&C: fill in the blanks?) 

+ Organizations develop a “PID-like ICD” which contains only the minimum necessary project/facility 
unique items. 

♦ List of functions within the MAL/COM/M&C specs which are to be implemented (assuming not all 
functions will be implemented - Perhaps accomplished with PICS-Proforma?) 

♦ List of IP addresses and agreed to secure authentication mechanisms 

♦ etc... (SM&C: fill in the blanks?) 

+ They sign the ICD and agree to the development schedule which supports the Operational Need Date. 
+ The service consumer organization develops the MAL, COM, M&C service interface code, etc. 

♦ (SM&C: fill in the blanks?) 

+ Develop “discovery” capability (auto config service?) and pub/sub server with discoverable service l/F 
+ Organizations conduct unit tests separately 
+ Organizations initiate and complete joint tests. 

+ Operational configuration is established (describe initiation of web services functions) 

+ Org A places service request calls to Org B and accessible services are displayed to consumer. 

+ Consumer selects telemetry service, selects specific parameters. 

+ Consumer connects service to display application and begins to stream RT TLM parameters. 

+ From then on, the operations teams have the ability to reconfigure set of TLM/CMD functions using 
discovery of services (operational configuration supersedes ICD agreements) 
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Program Scenario - where we think we are 

+ A service provider already has a service interface for Telemetry that complies with the SM&C 
document suite. 

+ A new service consumer needs to develop a service interface that will connect with it to access 
telemetry. 

+ The organizations agree to use SM&C M&C Standards. Each organization studies these documents: 

♦ MAL, COM, M&C, etc... (SM&C: fill in the blanks?) 

+ Organizations develop a “PID-like ICD” which contains: 

♦ Same as previous chart, plus... 

♦ Many more technical descriptions (layers, services, etc.) 

♦ Internal network architecture descriptions. 

♦ Encoding, XML Schema, XTCE Entity Definitions (should be discoverable) 

♦ Parameter definitions, Alert definitions (should be discoverable) 

♦ Common Model Operations, MAL data structures required for Directory Services, etc. 

+ They sign the ICD and agree to the development schedule which supports the Operational Need Date. 
+ The service consumer organization performs the same development activities as prior chart. 

+ Telecons and extensive coordination required outside of the necessary technical documents. 

+ Organizations conduct unit tests separately 

+ Organizations initiate and require extensive mods to complete joint tests. 

+ Operational configuration is established (describe initiation of web services functions) 

+ Org A places service request calls to Org B and begins final configuration. 

+ Consumer discovers more parameters are needed, initiates rework and resigning of ICD to add them. 
+ Consumer connects service to display application and begins to stream RT TLM parameters. 

+ From then on, additions of services require renegotiation of ICD and technical agreements, and 
software development changes rather than simple system reconfiguration. 
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Overall view of the components of interoperability 


Mission Ops 
Processes 


Systems 


Service Interfaces Systems 

x 


Mission Ops 
Processes 



Data Exchange Formats 


Data Exchange Formats 


Wire Protocols 


End-to-end Interoperability Processes 
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Explanation of MOSSG recommendations on Service Interfaces 

+ CCSDS SM&C has done outstanding groundwork in establishing a 
framework for Mission Operations Systems interoperability 

+ SM&C experts are highly qualified on what underlying capabilities are 
required for systems interoperability, and the MO Services architecture 
reflects that. 

+ External entities (like MOSSG) may not fully understand the implications of 
how interoperable services will drive the agencies’ underlying systems 
architecture. 

+ MOSSG grants to SM&C that the prescription of underlying system 
specifications issued so far are all probably necessary. 

+ We suggest, however, that now it’s time to focus on a prescriptive Service 
Interface that allows more automated configuration and setup of 
interoperable end-to-end processes than SM&C currently provides. 

+ SM&C “next steps” should focus on techniques for lightweight, adaptable 
service interfaces by exploring current web services technologies (HTML5, 
RESTful interfaces, etc.). 

+ Generic guideline: Wherever possible, the resulting service interfaces 
should decouple dependency on underlying systems architecture, so 
agencies can explore innovation in their internal systems architecture. 
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Systems and Processes relationships 


+ The MOSCG findings were that Mission Operations processes in 
general, did not need to be addressed by the MOSSG. 

♦ Flight control procedures, training, planning processes, etc. 

+ The MOSSG was chartered to address only Mission Operations 

Systems for interoperability 

♦ Including systems for procedures, planning, training, etc. 

+ However, there is an overlap where MO processes must be 

addressed 

♦ Process for how component-level services are developed and 
configured end-to-end to meet MO process requirements 

♦ Component-level services are MAL, COM, Common Services, 
etc. 

+ Besides specifying component-level services, SM&C and MOSSG 
also need to address the processes for integrating them with the 
end-to-end processes for interoperability. 

♦ If SM&C has already started this, it’s not apparent to the MOSSG or 
other external groups. 
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Conclusions 

+ CCSDS SM&C has done great work at establishing core capabilities 
for peer-to-peer Service Interfaces. 

+ The MOSSG concludes that more work is needed in the core 
standards to realize the “plug-n-play” vision. 

+ The MOSSG has also delivered “preliminary priorities” for future 
application-level services that run on the core MO Services 
capabilities established by SM&C. 

+ These preliminary priorities should be used cautiously because final 
priorities may change. 

+ However, SM&C sees fairly low risk in starting *some* application- 
level services and welcomes it if the resources don’t compete. 

+ If the resources do compete, CCSDS SM&C should consider 
whether Archive and File Management should be prioritized above 
the Planning BOF that is being organized at the next CCSDS 
meeting. 
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BACKUP 
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Various Interoperability Models (from SOSI rpt.) 


Information Exchange 

Level 

C o nip n ting En vironm en t 



Cross-domain information and 
applications sharing 
Advanced collaboration 
(Intel-active C'OP update, 
event-triggered global database update) 

4 

Enterprise 

Interactive manipulation 
Shared data aid applications 

wT nffn 

- 1 ™*.' . LjjU link HQ 

Level 

0: independent 

Shared databases 
Sophisticated collaboration 
(Common Operational Picture) 

3 

Domain 

Shared data 
“Separate" applications 

ni^la>vShar..l 

MGC'" a EM 

Level 

Level 

1 : ad hoc 
2: collaborative 

Heterogeneous product exchange 
Basic collaboration 
(Annotated imagery, maps w/ 
overlays) 

Homogeneous product 
exchange 

(F.M voice, tactical data links, 
text files, messages, e-mail) 

2 

Functional 

Minimal common functions 
Separate data aid applications 

1 

Connected 

Electronic connection 
Separate data aid applications 

[zS]"— 

t 

Level 

Level 

3: integrated 

(also called combined) 
4: unified 

Manual Gateway 
(diskette, tape, 
hard copy exchange) 

0 

Isolated 

Non-con aected 

' aha 




Levels of Information System Interoperability (LISI) Model 


Organizational Interoperability Maturity (OIM) Model 
(Clark and Jones) 


n 

2 

a 

c. 

2 

01 

£ 

c 

o 

; 

re 

o 

o 


e 

<U 

>. 

re 


Political Objectives 


Harmonized Strategy/Doctrlnes 


Aligned Operations 


Aligned Procedures 


Knowledge/Awareness 


Information Interoperability 


Data/Object Model interoperability 


Protocol Interoperability 


Physical Interoperability 


Organizational 1 
ntero pe- ability | 


USI I evil-, 


X 


Technical 

Interoperability 


ical 

ability 


Orgamsntional Levels 


People Emphasis 

t'2 Frameworks 
C2 Processes 
Information Mgt 


Enterprise 


Unified / 


Combined / 


Collaborapve 

Y'''" 

Ad hoof 

IiuL4cndcnl 


j, ^ X 

\ Domain 


functional 

/ Coniicelcil 



Isolated 


Technology Emphasis 
Information Mgt 
Information Technology 
Telecommunications 


Layers of Coalition Interoperability (LCI) Model (Tolk) 
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Alignment between Organizational model and LISI (from SOSI) 


4 - 


An MOSSG Simplified Interoperability Model 



Teams have common management structure, use ail 
the same tools, interfaces are not an issue. 



High: Shared Common Applications 
Developed to multi-agency requirements. 


Agencies acquire common systems 
(executable SW, not just interfaces); 
Team members have common tools and 
common training on those tools. 



Service level 
(SM&C) 


Moderate: Consensus Standardized Interfaces 
Multi-program; Multi-Agency, developed collaboratively. 


Agencies develop different systems to 
common interfaces 


Data Format 
Level 



Minimal: Single Agency Interfaces applied to multiple agencies 
Program-unique; Not designed for reuse; Not developed collaboratively. 


ISS Case (in general): Lead 
agency specifies exchange 
data formats 



Essentially None: Reliance on public infrastructure such as voice calls 
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